Fix broken rich text blocks in layout picker preview in Firefox #43822
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ending DOM elements, to resolve failing rich text blocks in Firefox
|
This PR does not affect the size of JS and CSS bundles shipped to the user's browser. Generated by performance advisor bot at iscalypsofastyet.com. |
andrewserong
added
[Status] Needs Review
|
Caution: This PR affects files in the FSE Plugin on WordPress.com D45752-code has been created so you can easily test it on your sandbox. See this FieldGuide page about developing in the FSE Plugin for more info: PCYsg-ly5-p2 |
Addison-Stavlo
approved these changes
Jul 1, 2020
andrewserong
deleted the
fix/layout-picker-load-rich-text-block-previews-in-firefox
branch
matticbot
removed
the
[Status] Needs Review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix for #43611 where the preview for layouts containing RichText components would fail on the first render, but if you then clicked on other layouts, it would render correctly. This appeared to only affect Firefox, as Chrome looked OK.
In Firefox, when first previewing a layout that contains RichText elements, the blocks would fail rendering when calling
createElementin Gutenberg. I'm not 100% sure of the cause, but the issue only occurred when we append therenderedBlocksDOMto the iframe. My suspicion is that becausecreateElementre-uses a single document, creating that document outside of the iFrame context fails when it's added to the iFrame context. Then the subsequent time it's called, perhaps because it's in a fresh context, the subsequent calls work fine.Whatever the actual cause, swapping out the use of two refs, where we render in the parent context and then
appendChildto the iframe, and instead usingcreatePortalto render directly to the iFrame, appears to fix the issue.Changes proposed in this Pull Request
renderedBlocksRefand usecreatePortalto render the<CustomBlockPreview>directly in the iFrame.Screenshot (before)
Screenshot (after)
Testing instructions
Verify that you can replicate the issue in Add new page - template content doesn't show up in Firefox #43611
Sandbox the FSE plugin changes (D45752-code), and your test site
In Firefox, go to add a new page in your test site. From the initial "Blank" layout, select a layout that contains
RichTextcomponents (e.g. paragraphs and headings) — any of the About pages should do it.On first render, the blocks should render correctly and not throw errors (note: many of the layouts do throw unexpected block errors, e.g. Jetpack contact forms / latest posts blocks — these are pre-existing issues and not related to this change)
Test across Chrome, Edge, IE, etc to make sure there are no regressions.
Fixes #43611